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Abstract 


The application-specific routing requirements for Urban Low-Power and 
Lossy Networks (U-LLNs) are presented in this document. In the near 
future, sensing and actuating nodes will be placed outdoors in urban 
environments so as to improve people’s living conditions as well as 
to monitor compliance with increasingly strict environmental laws. 
These field nodes are expected to measure and report a wide gamut of 
data (for example, the data required by applications that perform 
smart-metering or that monitor meteorological, pollution, and allergy 
conditions). The majority of these nodes are expected to communicate 
wirelessly over a variety of links such as IEEE 802.15.4, low-power 
IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited 
radio range and the large number of nodes requires the use of 
suitable routing protocols. The design of such protocols will be 
mainly impacted by the limited resources of the nodes (memory, 
processing power, battery, etc.) and the particularities of the 
outdoor urban application scenarios. As such, for a wireless 
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solution for Routing Over Low-Power and Lossy (ROLL) networks to be 
useful, the protocol(s) ought to be energy-efficient, scalable, and 
autonomous. This documents aims to specify a set of IPv6 routing 
requirements reflecting these and further U-LLNs’ tailored 
characteristics. 
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Les 


Introduction 


This document details application-specific IPv6 routing requirements 
for Urban Low-Power and Lossy Networks (U-LLNs). Note that this 
document details the set of IPv6 routing requirements for U-LLNs in 
strict compliance with the layered IP architecture. U-LLN use cases 
and associated routing protocol requirements will be described. 


Section 2 defines terminology useful in describing U-LLNs. 


Section 3 provides an overview of U-LLN applications. 


Section 4 describes a few typical use cases for U-LLN applications 
exemplifying deployment problems and related routing issues. 


Section 5 describes traffic flows that will be typical for U-LLN 
applications. 


Section 6 discusses the routing requirements for networks comprising 
such constrained devices in a U-LLN environment. These requirements 
may overlap with or be derived from other application-specific 
requirements documents [ROLL-HOME] [ROLL-INDUS] [ROLL-BUILD]. 


Section 7 provides an overview of routing security considerations of 
U-LLN implementations. 


Terminology 


The terminology used in this document is consistent with and 
incorporates that described in "Terminology in Low power And Lossy 
Networks" [ROLL-TERM]. This terminology is extended in this document 
as follows: 


Anycast: Addressing and Routing scheme for forwarding packets to at 
least one of the "nearest" interfaces from a group, as 
described in RFC4291 [RFC4291] and RFC1546 [RFC1546]. 


Autonomous: Refers to the ability of a routing protocol to 
independently function without requiring any external 
influence or guidance. Includes self-configuration and 


self-organization capabilities. 


DoS: Denial of Service, a class of attack that attempts to cause 
resource exhaustion to the detriment of a node or network. 
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ISM band: Industrial, Scientific, and Medical band. This is a 
region of radio spectrum where low-power, unlicensed 
devices may generally be used, with specific guidance from 
an applicable local radio spectrum authority. 

U-LLN: Urban Low-Power and Lossy Network. 

WLAN: Wireless Local Area Network. 

2.1. Requirements Language 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

document are to be interpreted as described in RFC 2119 [RFC2119]. 

3. Overview of Urban Low-Power and Lossy Networks 


3.1. Canonical Network Elements 


A U-LLN is understood to be a network composed of three key elements, 


i.e., 

1. sensors, 

2. actuators, and 
3. routers 


that communicate wirelessly. The aim of the following sections 
(3.1.1, 3.1.2, and 3.1.3) is to illustrate the functional nature of a 
sensor, actuator, and router in this context. That said, it must be 
understood that these functionalities are not exclusive. A 
particular device may act as a simple router or may alternatively be 
a router equipped with a sensing functionality, in which case it will 
be seen as a "regular" router as far as routing is concerned. 


3.1.1. Sensors 


Sensing nodes measure a wide gamut of physical data, including but 
not limited to: 


1. municipal consumption data, such as smart-metering of gas, water, 
electricity, waste, etc.; 


2. meteorological data, such as temperature, pressure, humidity, UV 
index, strength and direction of wind, etc.; 
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3. pollution data, such as gases (sulfur dioxide, nitrogen oxide, 
carbon monoxide, ozone), heavy metals (e.g., mercury), pH, 
radioactivity, etc.; 


4. ambient data, such as levels of allergens (pollen, dust), 
electromagnetic pollution, noise, etc. 


Sensor nodes run applications that typically gather the measurement 
data and send it to data collection and processing application(s) on 
other node(s) (often outside the U-LLN). 


Sensor nodes are capable of forwarding data. Sensor nodes are 
generally not mobile in the majority of near-future roll-outs. In 
many anticipated roll-outs, sensor nodes may suffer from long-term 
resource constraints. 


A prominent example is a "Smart grid" application that consists of a 
city-wide network of smart meters and distribution monitoring 


sensors. Smart meters in an urban "smart grid" application will 
include electric, gas, and/or water meters typically administered by 
one or multiple utility companies. These meters will be capable of 


advanced sensing functionalities such as measuring the quality of 
electrical service provided to a customer, providing granular 
interval data, or automating the detection of alarm conditions. In 
addition, they may be capable of advanced interactive 
functionalities, which may invoke an actuator component, such as 
remote service disconnect or remote demand reset. More advanced 
scenarios include demand response systems for managing peak load, and 
distribution automation systems to monitor the infrastructure that 
delivers energy throughout the urban environment. Sensor nodes 
capable of providing this type of functionality may sometimes be 
referred to as Advanced Metering Infrastructure (AMI). 


3.1.2. Actuators 


Actuator nodes are capable of controlling urban devices; examples are 


street or traffic lights. They run applications that receive 
instructions from control applications on other nodes (possibly 
outside the U-LLN). The amount of actuator points is well below the 
number of sensing nodes. Some sensing nodes may include an actuator 


component, e.g., an electric meter node with integrated support for 
remote service disconnect. Actuators are capable of forwarding data. 
Actuators are not likely to be mobile in the majority of near-future 
roll-outs. Actuator nodes may also suffer from long-term resource 
constraints, e.g., in the case where they are battery powered. 
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3.1.3. Routers 


Routers generally act to close coverage and routing gaps within the 
interior of the U-LLN; examples of their use are: 


1. prolong the U-LLN’s lifetime, 
2. balance nodes’ energy depletion, and 
3. build advanced sensing infrastructures. 


There can be several routers supporting the same U-LLN; however, the 
number of routers is well below the amount of sensing nodes. The 
routers are generally not mobile, i.e., fixed to a random or pre- 
planned location. Routers may, but generally do not, suffer from any 
form of (long-term) resource constraint, except that they need to be 
small and sufficiently cheap. Routers differ from actuator and 


sensing nodes in that they neither control nor sense. That being 
said, a sensing node or actuator may also be a router within the 
U-LLN. 


Some routers provide access to wider infrastructures, such as the 
Internet, and are named Low-Power and Lossy Network Border Routers 
(LBRs) in that context. 


LBR nodes in particular may also run applications that communicate 
with sensor and actuator nodes (e.g., collecting and processing data 
from sensor applications, or sending instructions to actuator 
applications). 


3.2. Topology 


Whilst millions of sensing nodes may very well be deployed in an 
urban area, they are likely to be associated with more than one 
network. These networks may or may not communicate between one 
another. The number of sensing nodes deployed in the urban 
environment in support of some applications is expected to be in the 
order of 10%2 to 10^7; this is still very large and unprecedented in 
current roll-outs. 


Deployment of nodes is likely to happen in batches, e.g., boxes of 
hundreds to thousands of nodes arrive and are deployed. The location 
of the nodes is random within given topological constraints, e.g., 
placement along a road, river, or at individual residences. 
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3.3. Resource Constraints 


The nodes are highly resource constrained, i.e., cheap hardware, low 
memory, and no infinite energy source. Different node powering 
mechanisms are available, such as: 


1. non-rechargeable battery; 
2. rechargeable battery with regular recharging (e.g., sunlight); 
3. rechargeable battery with irregular recharging (e.g., 


opportunistic energy scavenging); 


4. capacitive/inductive energy provision (e.g., passive Radio 
Frequency IDentification (RFID)); 


5. always on (e.g., powered electricity meter). 
In the case of a battery-powered sensing node, the battery shelf life 


is usually in the order of 10 to 15 years, rendering network lifetime 
maximization with battery-powered nodes beyond this lifespan useless. 


The physical and electromagnetic distances between the three key 
elements, i.e., sensors, actuators, and routers, can generally be 
very large, i.e., from several hundreds of meters to one kilometer. 
Not every field node is likely to reach the LBR in a single hop, 
thereby requiring suitable routing protocols that manage the 
information flow in an energy-efficient manner. 


3.4. Link Reliability 


The links between the network elements are volatile due to the 
following set of non-exclusive effects: 


1. packet errors due to wireless channel effects; 
2. packet errors due to MAC (Medium Access Control) (e.g., 
collision) ; 


3. packet errors due to interference from other systems; 

4. link unavailability due to network dynamicity; etc. 

The wireless channel causes the received power to drop below a given 
threshold in a random fashion, thereby causing detection errors in 


the receiving node. The underlying effects are path loss, shadowing 
and fading. 
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Since the wireless medium is broadcast in nature, nodes in their 
communication radios require suitable medium access control protocols 
that are capable of resolving any arising contention. Some available 
protocols may not be able to prevent packets of neighboring nodes 
from colliding, possibly leading to a high Packet Error Rate (PER) 
and causing a link outage. 


Furthermore, the outdoor deployment of U-LLNs also has implications 
for the interference temperature and hence link reliability and range 
if Industrial, Scientific, and Medical (ISM) bands are to be used. 
For instance, if the 2.4 GHz ISM band is used to facilitate 
communication between U-LLN nodes, then heavily loaded Wireless Local 
Area Network (WLAN) hot-spots may become a detrimental performance 
factor, leading to high PER and jeopardizing the functioning of the 
U-LLN. 


Finally, nodes appearing and disappearing causes dynamics in the 
network that can yield link outages and changes of topologies. 


4. Urban LLN Application Scenarios 


Urban applications represent a special segment of LLNs with its 
unique set of requirements. To facilitate the requirements 
discussion in Section 6, this section lists a few typical but not 
exhaustive deployment problems and usage cases of U-LLN. 


4.1. Deployment of Nodes 


Contrary to other LLN applications, deployment of nodes is likely to 
happen in batches out of a box. Typically, hundreds to thousands of 
nodes are being shipped by the manufacturer with pre-programmed 
functionalities which are then rolled-out by a service provider or 
subcontracted entities. Prior to or after roll-out, the network 
needs to be ramped-up. This initialization phase may include, among 
others, allocation of addresses, (possibly hierarchical) roles in the 
network, synchronization, determination of schedules, etc. 


If initialization is performed prior to roll-out, all nodes are 
likely to be in one another’s one-hop radio neighborhood. Pre- 
programmed Media Access Control (MAC) and routing protocols may hence 
fail to function properly, thereby wasting a large amount of energy. 
Whilst the major burden will be on resolving MAC conflicts, any 
proposed U-LLN routing protocol needs to cater for such a case. For 
instance, zero-configuration and network address allocation needs to 
be properly supported, etc. 


Dohler, et al. Informational [Page 8] 


RFC 5548 Routing Requirements for U-LLNs May 2009 


After roll-out, nodes will have a finite set of one-hop neighbors, 


likely of low cardinality (in the order of 5 to 10). However, some 
nodes may be deployed in areas where there are hundreds of 
neighboring devices. In the resulting topology, there may be regions 


where many (redundant) paths are possible through the network. Other 
regions may De dependent on critical links to achieve connectivity 
with the rest of the network. Any proposed LIN routing protocol 
ought to support the autonomous self-organization and self- 
configuration of the network at lowest possible energy cost [Lu2007], 
where autonomy is understood to be the ability of the network to 
operate without external influence. The result of such organization 
should be that each node or set of nodes is uniquely addressable so 
as to facilitate the set up of schedules, etc. 


Unless exceptionally needed, broadcast forwarding schemes are not 
advised in urban sensor networking environments. 


4.2. Association and Disassociation/Disappearance of Nodes 


After the initialization phase and possibly some operational time, 
new nodes may be injected into the network as well as existing nodes 
removed from the network. The former might be because a removed node 
is replaced as part of maintenance, or new nodes are added because 
more sensors for denser readings/actuations are needed, or because 
routing protocols report connectivity problems. The latter might be 
because a node's battery is depleted, the node is removed for 
maintenance, the node is stolen or accidentally destroyed, etc. 


The protocol tel hence should be able to convey information about 
malfunctioning nodes that may affect or jeopardize the overall 
routing efficiency, so that self-organization and self-configuration 
capabilities of the sensor network might be solicited to facilitate 
the appropriate reconfiguration. This information may include, e.g., 
exact or relative geographical position, etc. The reconfiguration 
may include the change of hierarchies, routing paths, packet 
forwarding schedules, etc. Furthermore, to inform the LBR(s) of the 
node’s arrival and association with the network as well as freshly 
associated nodes about packet forwarding schedules, roles, etc., 
appropriate updating mechanisms should be supported. 


4.3. Regular Measurement Reporting 


The majority of sensing nodes will be configured to report their 
readings on a regular basis. The frequency of data sensing and 
reporting may be different but is generally expected to be fairly 
low, i.e., in the range of once per hour, per day, etc. The ratio 
between data sensing and reporting frequencies will determine the 
memory and data aggregation capabilities of the nodes. Latency of an 
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end-to-end delivery and acknowledgements of a successful data 
delivery may not be vital as sensing outages can be observed at data 
collection applications -- when, for instance, there is no reading 
arriving from a given sensor or cluster of sensors within a day. In 
this case, a query Can be launched to check upon the state and 
availability of a sensing node or sensing cluster. 


It is not uncommon to gather data on a few servers located outside of 
the U-LLN. In such cases, a large number of highly directional 
unicast flows from the sensing nodes or sensing clusters are likely 
to transit through a LBR. Thus, the protocol(s) should be optimized 
to support a large number of unicast flows from the sensing nodes or 
sensing clusters towards a LBR, or highly directed multicast or 
anycast flows from the nodes towards multiple LBRs. 


Route computation and selection may depend on the transmitted 
information, the frequency of reporting, the amount of energy 
remaining in the nodes, the recharging pattern of energy-scavenged 
nodes, etc. For instance, temperature readings could be reported 
every hour via one set of battery-powered nodes, whereas air quality 
indicators are reported only during the daytime via nodes powered by 
solar energy. More generally, entire routing areas may be avoided 
(e.g., at night) but heavily used during the day when nodes are 
scavenging energy from sunlight. 


4.4. Queried Measurement Reporting 


Occasionally, network-external data queries can be launched by one or 
several applications. For instance, it is desirable to know the 
level of pollution at a specific point or along a given road in the 
urban environment. The queries’ rates of occurrence are not regular 
but rather random, where heavy-tail distributions seem appropriate to 
model their behavior. Queries do not necessarily need to be reported 
back to the same node from where the query was launched. Round-trip 
times, i.e., from the launch of a query from a node until the 
delivery of the measured data to a node, are of importance. However, 
they are not very stringent where latencies should simply be 
sufficiently smaller than typical reporting intervals; for instance, 
in the order of seconds or minutes. The routing protocol(s) should 
consider the selection of paths with appropriate (e.g., latency) 
metrics to support queried measurement reporting. To facilitate the 
query process, U-LLN devices should support unicast and multicast 
routing capabilities. 


The same approach is also applicable for schedule update, 
provisioning of patches and upgrades, etc. In this case, however, 
the provision of acknowledgements and the support of unicast, 
multicast, and anycast are of importance. 
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4.5. Alert Reporting 


Rarely, the sensing nodes will measure an event that classifies as an 
alarm where such a classification is typically done locally within 
each node by means of a pre-programmed or prior-diffused threshold. 
Note that on approaching the alert threshold level, nodes may wish to 
change their sensing and reporting cycles. An alarm is likely being 
registered by a plurality of sensing nodes where the delivery of a 
single alert message with its location of origin suffices in most, 
but not all, cases. One example of alert reporting is if the level 
of toxic gases rises above a threshold; thereupon, the sensing nodes 
in the vicinity of this event report the danger. Another example of 
alert reporting is when a recycling glass container -- equipped with 
a sensor measuring its level of occupancy -- reports that the 
container is full and hence needs to be emptied. 


Routes clearly need to be unicast (towards one LBR) or multicast 
(towards multiple LBRs). Delays and latencies are important; 
however, for a U-LLN deployed in support of a typical application, 
deliveries within seconds should suffice in most of the cases. 


5. Traffic Pattern 


Unlike traditional ad hoc networks, the information flow in U-LLNs is 
highly directional. There are three main flows to be distinguished: 


1. sensed information from the sensing nodes to applications outside 
the U-LLN, going through one or a subset of the LBR(s); 


2. query requests from applications outside the U-LLN, going through 
the LBR(s) towards the sensing nodes; 


3. control information from applications outside the U-LLN, going 
through the LBR(s) towards the actuators. 


Some of the flows may need the reverse route for delivering 
acknowledgements. Finally, in the future, some direct information 
flows between field devices without LBRs may also occur. 


Sensed data is likely to be highly correlated in space, time, and 
observed events; an example of the latter is when temperature 
increase and humidity decrease as the day commences. Data may be 
sensed and delivered at different rates with both rates being 
typically fairly low, i.e., in the range of minutes, hours, days, 
etc. Data may be delivered regularly according to a schedule or a 
regular query; it may also be delivered irregularly after an 
externally triggered query; it may also be triggered after a sudden 
network-internal event or alert. Schedules may be driven by, for 
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example, a smart-metering application where data is expected to be 
delivered every hour, or an environmental monitoring application 
where a battery-powered node is expected to report its status at a 
specific time once a day. Data delivery may trigger acknowledgements 
or maintenance traffic in the reverse direction. The network hence 
needs to be able to adjust to the varying activity duty cycles, as 
well as to periodic and sporadic traffic. Also, sensed data ought to 
be secured and locatable. 


Some data delivery may have tight latency requirements, for example, 
in a case such as a live meter reading for customer service ina 
smart-metering application, or in a case where a sensor reading 
response must arrive within a certain time in order to be useful. 

The network should take into consideration that different application 
traffic may require different priorities in the selection of a route 
when traversing the network, and that some traffic may be more 
sensitive to latency. 


A U-LLN should support occasional large-scale traffic flows from 
sensing nodes through LBRs (to nodes outside the U-LLN), such as 
system-wide alerts. In the example of an AMI U-LLN, this could be in 
response to events such as a city-wide power outage. In this 
scenario, all powered devices in a large segment of the network may 
have lost power and be running off of a temporary "last gasp" source 
such aS a capacitor or small battery. A node must be able to send 
its own alerts toward an LBR while continuing to forward traffic on 
behalf of other devices that are also experiencing an alert 
condition. The network needs to be able to manage this sudden large 
traffic flow. 


A U-LLN may also need to support efficient large-scale messaging to 
groups of actuators. For example, an AMI U-LLN supporting a city- 
wide demand response system will need to efficiently broadcast 
demand-response control information to a large subset of actuators in 
the system. 


Some scenarios will require internetworking between the U-LLN and 
another network, such as a home network. For example, an AMI 
application that implements a demand-response system may need to 
forward traffic from a utility, across the U-LLN, into a home 
automation network. A typical use case would be to inform a customer 
of incentives to reduce demand during peaks, or to automatically 
adjust the thermostat of customers who have enrolled in such a demand 
management program. Subsequent traffic may be triggered to flow back 
through the U-LLN to the utility. 
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6. Requirements of Urban-LLN Applications 
Urban Low-Power and Lossy Network applications have a number of 
specific requirements related to the set of operating conditions, as 


exemplified in the previous sections. 


6.1. Scalability 


The large and diverse measurement space of U-LLN nodes -- coupled 
with the typically large urban areas -- will yield extremely large 
network sizes. Current urban roll-outs are composed of sometimes 
more than one hundred nodes; future roll-outs, however, may easily 
reach numbers in the tens of thousands to millions. One of the 
utmost important LIN routing protocol design criteria is hence 
scalability. 


The routing protocol (s) MUST be capable of supporting the 
organization of a large number of sensing nodes into regions 
containing on the order of 10%2 to 10^4 sensing nodes each. 


The routing protocol (s) MUST be scalable so as to accommodate a very 
large and increasing number of nodes without deteriorating selected 
performance parameters below configurable thresholds. The routing 
protocols(s) SHOULD support the organization of a large number of 
nodes into regions of configurable size. 


6.2. Parameter-Constrained Routing 


Batteries in some nodes may deplete quicker than in others; the 
existence of one node for the maintenance of a routing path may not 
be as important as of another node; the energy-scavenging methods may 
recharge the battery at regular or irregular intervals; some nodes 
may have a constant power source; some nodes may have a larger memory 
and are hence be able to store more neighborhood information; some 
nodes may have a stronger CPU and are hence able to perform more 
sophisticated data aggregation methods, etc. 


To this end, the routing protocol (s) MUST support parameter- 
constrained routing, where examples of such parameters (CPU, memory 
size, battery level, etc.) have been given in the previous paragraph. 
In other words, the routing protocol MUST be able to advertise node 
capabilities that will be exclusively used by the routing protocol 
engine for routing decision. For the sake of example, such a 
capability could be related to the node capability itself (e.g., 
remaining power) or some application that could influence routing 
(e.g., capability to aggregate data). 
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Routing within urban sensor networks SHOULD require the U-LLN nodes 
to dynamically compute, select, and install different paths towards 
the same destination, depending on the nature of the traffic. Such 
functionality in support of, for example, data aggregation, may imply 
use of some mechanisms to mark/tag the traffic for appropriate 
routing decision using the IPv6 packet format (e.g., use of Diffserv 
Code Point (DSCP), Flow Label) based on an upper-layer marking 
decision. From this perspective, such nodes MAY use node 
capabilities (e.g., to act as an aggregator) in conjunction with the 
anycast endpoints and packet marking to route the traffic. 


6.3. Support of Autonomous and Alien Configuration 


With the large number of nodes, manually configuring and 
troubleshooting each node is not efficient. The scale and the large 
number of possible topologies that may be encountered in the U-LLN 
encourages the development of automated management capabilities that 
may (partly) rely upon self-organizing techniques. The network is 
expected to self-organize and self-configure according to some prior 
defined rules and protocols, as well as to support externally 
triggered configurations (for instance, through a commissioning tool 
that may facilitate the organization of the network at a minimum 
energy cost). 


To this end, the routing protocol(s) MUST provide a set of features 
including zero-configuration at network ramp-up, (network-internal) 
self-organization and configuration due to topological changes, and 
the ability to support (network-external) patches and configuration 
updates. For the latter, the protocol(s) MUST support multicast and 
anycast addressing. The protocol(s) SHOULD also support the 
formation and identification of groups of field devices in the 
network. 


The routing protocol(s) SHOULD be able to dynamically adapt, e.g., 
through the application of appropriate routing metrics, to ever- 
changing conditions of communication (possible degradation of quality 
of service (QoS), variable nature of the traffic (real-time versus 
non-real-time, sensed data versus alerts), node mobility, a 
combination thereof, etc.). 


The routing protocol(s) SHOULD be able to dynamically compute, 
select, and possibly optimize the (multiple) path(s) that will be 
used by the participating devices to forward the traffic towards the 
actuators and/or a LBR according to the service-specific and traffic- 
specific QoS, traffic engineering, and routing security policies that 
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will have to be enforced at the scale of a routing domain (that is, a 
set of networking devices administered by a globally unique entity), 
or a region of such domain (e.g., a metropolitan area composed of 
clusters of sensors). 


6.4. Support of Highly Directed Information Flows 


As pointed out in Section 4.3, it is not uncommon to gather data ona 
few servers located outside of the U-LLN. In this case, the 
reporting of the data readings by a large amount of spatially 
dispersed nodes towards a few LBRs will lead to highly directed 
information flows. For instance, a suitable addressing scheme can be 
devised that facilitates the data flow. Also, as one gets closer to 
the LBR, the traffic concentration increases, which may lead to high 
load imbalances in node usage. 


To this end, the routing protocol(s) SHOULD support and utilize the 
large number of highly directed traffic flows to facilitate 
scalability and parameter-constrained routing. 


The routing protocol MUST be able to accommodate traffic bursts by 
dynamically computing and selecting multiple paths towards the same 
destination. 


6.5. Support of Multicast and Anycast 


Routing protocols activated in urban sensor networks MUST support 
unicast (traffic is sent to a single field device), multicast 
(traffic is sent to a set of devices that are subscribed to the same 
multicast group), and anycast (where multiple field devices are 
configured to accept traffic sent on a single IP anycast address) 
transmission schemes. 


The support of unicast, multicast, and anycast also has an 
implication on the addressing scheme, but it is beyond the scope of 
this document that focuses on the routing requirements. 


Some urban sensing systems may require low-level addressing of a 
group of nodes in the same subnet, or for a node representative of a 
group of nodes, without any prior creation of multicast groups. Such 
addressing schemes, where a sender can form an addressable group of 
receivers, are not currently supported by IPv6, and not further 
discussed in this specification [ROLL-HOME]. 


The network SHOULD support internetworking when identical protocols 


are used, while giving attention to routing security implications of 
interfacing, for example, a home network with a utility U-LLN. The 
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network may support the ability to interact with another network 
using a different protocol, for example, by supporting route 
redistribution. 


6.6. Network Dynamicity 


Although mobility is assumed to be low in urban LLNs, network 
dynamicity due to node association, disassociation, and 
disappearance, as well as long-term link perturbations is not 
negligible. This in turn impacts reorganization and reconfiguration 
convergence as well as routing protocol convergence. 


To this end, local network dynamics SHOULD NOT impact the entire 
network to be reorganized or re-reconfigured; however, the network 
SHOULD be locally optimized to cater for the encountered changes. 

The routing protocol (s) SHOULD support appropriate mechanisms in 
order to be informed of the association, disassociation, and 
disappearance of nodes. The routing protocol (s) SHOULD support 
appropriate updating mechanisms in order to be informed of changes in 
connectivity. The routing protocol(s) SHOULD use this information to 
initiate protocol-specific mechanisms for reorganization and 
reconfiguration as necessary to maintain overall routing efficiency. 
Convergence and route establishment times SHOULD be significantly 
lower than the smallest reporting interval. 


Differentiation SHOULD be made between node disappearance, where the 
node disappears without prior notification, and user- or node- 
initiated disassociation ("phased-out"), where the node has enough 
time to inform the network about its pending removal. 


6.7. Latency 


With the exception of alert-reporting solutions and (to a certain 
extent) queried reporting, U-LLNs are delay tolerant as long as the 
information arrives within a fraction of the smallest reporting 
interval, e.g., a few seconds if reporting is done every 4 hours. 


The routing protocol(s) SHOULD also support the ability to route 
according to different metrics (one of which could, e.g., be 
latency). 


7. Security Considerations 


As every network, U-LLNs are exposed to routing security threats that 
need to be addressed. The wireless and distributed nature of these 
networks increases the spectrum of potential routing security 
threats. This is further amplified by the resource constraints of 
the nodes, thereby preventing resource-intensive routing security 
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approaches from being deployed. A viable routing security approach 
SHOULD be sufficiently lightweight that it may be implemented across 
all nodes in a U-LLN. These issues require special attention during 
the design process, so as to facilitate a commercially attractive 
deployment. 


The U-LLN MUST deny any node that has not been authenticated to the 
U-LLN and authorized to participate to the routing decision process. 


An attacker SHOULD be prevented from manipulating or disabling the 
routing function, for example, by compromising routing control 
messages. To this end, the routing protocol(s) MUST support message 
integrity. 


Further examples of routing security issues that may arise are the 
abnormal behavior of nodes that exhibit an egoistic conduct, such as 
not obeying network rules or forwarding no or false packets. Other 
important issues may arise in the context of denial-of-service (DoS) 
attacks, malicious address space allocations, advertisement of 
variable addresses, a wrong neighborhood, etc. The routing 
protocol(s) SHOULD support defense against DoS attacks and other 
attempts to maliciously or inadvertently cause the mechanisms of the 
routing protocol(s) to over-consume the limited resources of LLN 
nodes, e.g., by constructing forwarding loops or causing excessive 
routing protocol overhead traffic, etc. 


The properties of self-configuration and self-organization that are 
desirable in a U-LLN introduce additional routing security 
considerations. Mechanisms MUST be in place to deny any node that 
attempts to take malicious advantage of self-configuration and self- 
organization procedures. Such attacks may attempt, for example, to 
cause DoS, drain the energy of power-constrained devices, or to 
hijack the routing mechanism. A node MUST authenticate itself to a 
trusted node that is already associated with the U-LLN before the 
former can take part in self-configuration or self-organization. A 
node that has already authenticated and associated with the U-LLN 
MUST deny, to the maximum extent possible, the allocation of 
resources to any unauthenticated peer. The routing protocol (s) MUST 
deny service to any node that has not clearly established trust with 
the U-LLN. 


Consideration SHOULD be given to cases where the U-LLN may interface 
with other networks such as a home network. The U-LLN SHOULD NOT 
interface with any external network that has not established trust. 
The U-LLN SHOULD be capable of limiting the resources granted in 
support of an external network so as not to be vulnerable to DoS. 
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With low computation power and scarce energy resources, U-LLNs’ nodes 
may not be able to resist any attack from high-power malicious nodes 
(e.g., laptops and strong radios). However, the amount of damage 
generated to the whole network SHOULD be commensurate with the number 
of nodes physically compromised. For example, an intruder taking 
control over a single node SHOULD NOT be able to completely deny 
service to the whole network. 


In general, the routing protocol(s) SHOULD support the implementation 
of routing security best practices across the U-LLN. Such an 
implementation ought to include defense against, for example, 
eavesdropping, replay, message insertion, modification, and man-in- 
the-middle attacks. 


The choice of the routing security solutions will have an impact on 
the routing protocol(s). To this end, routing protocol(s) proposed 
in the context of U-LLNs MUST support authentication and integrity 
measures and SHOULD support confidentiality (routing security) 
measures. 
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